home *** CD-ROM | disk | FTP | other *** search
Text File | 1990-02-23 | 1.9 KB | 46 lines | [TEXT/GEOL] |
- Item 4434659 22-Feb-90 11:19PST
-
- From: ALGER Alger, Jeff,VCA
-
- To: MUYSVASOVIC ACE - Jean-Denis Muys-Vasovic
-
- cc: MACAPP.TECH$ MacApp Technical
-
- Sub: Re: Re: Persistent…
-
- Jean-Denis,
-
- To respond to the issues you raised:
-
- 1. TList et al must provide explicit support for the ownership (or lack
- thereof) of their referenced objects. It would seem reasonable to have two
- versions (subclasses): one of which owns its objects and one of which does not.
- Again, I must emphasize that default behavior must be overridable! This is one
- example of why: Object Pascal does not support collections in the language,
- therefore it is up to classes to do their own dirty work. OP can only help
- with information it is given.
-
- 2. In you hypothetical example, I would say that the document owns the new
- thing. The TCommand could request that the document get rid of it, but the
- document itself should do the freeing. (You left out in your sample code a
- call to the document to remove it from the TList. This could have done the
- freeing.)
-
- On a more general note before the links start rolling in: yes, ownership is not
- a cut and dried issue. There are PhD theses written on the topic in database
- circles. However, that should not stop one from creating generally useful
- default behavior. Most ownership is straightforward and one of two types:
-
- • Parent-child ownership.
- • Existence constraints (X ceases to exist when no one refers to it anymore.)
-
- The latter is garbage collection, as you properly point out. The former
- involves capturing more semantic information about the data and is the real
- object of my suggestion. In any case, this is made all the easier to address
- because this is OOP: default behavior which does not fit the circumstances can
- be overridden.
-
- Jeff Alger
- KPMG Peat Marwick
-
-